前言
在 Day 5 中，我們使用 Docker Compose 順利啟動了本地端的 HAPI FHIR JPA Server（http://localhost:8080/fhir）。

在標準 Web 開發中，RESTful API 通常由開發團隊自行定義路由規則與查詢字串（例如 /api/v1/get-patient-by-id）。但在 FHIR 的規範世界裡，所有的 HTTP 操作動詞、URL 路徑規格、標頭（Headers）要求與查詢參數（Search Parameters），全都受到嚴格的國際標準約束。

今天我們將以 Postman 與 cURL 作為測試工具，實機操作 FHIR 的 Create (POST)、Read (GET)、Update (PUT)、Delete (DELETE)，並深入演練臨床開發中最常用的 Search Parameters 條件查詢與 Bundle 分頁機制。

一、FHIR HTTP 請求標頭規範
在發送任何請求給 FHIR Server 之前，必須在 Request Header 中宣告合規的 MIME Type：

-Content-Type: application/fhir+json：告訴伺服器請求主體是標準 FHIR JSON 格式。
-Accept: application/fhir+json：要求伺服器必須以標準 FHIR JSON 格式回傳結果。

注意： 雖然部分寬鬆的 Server 允許使用一般的 application/json，但標準的 FHIR Gateway 或驗證伺服器若未檢測到 application/fhir+json，可能會拒絕連線或回傳 415 Unsupported Media Type。

二、實戰 CRUD 操作演練

1. Create（新增資源）：POST
   將 Day 3 定義的病患資料寫入伺服器。在 FHIR 中，當我們使用 POST 新增時，通常不需要手動指定 id，伺服器會自動配發一個邏輯 ID。

cURL 範例：

伺服器回應特徵：
-HTTP 狀態碼： 201 Created
-Response Header： 會包含 Location: http://localhost:8080/fhir/Patient/1/_history/1，其中的 1 即為系統生成的資源 ID。
-ETag Header： 回傳版本號（例如 W/"1"），供後續樂觀鎖（Optimistic Locking）檢核。

2. Read（讀取單筆資源）：GET
   讀取指定 ID 的資源內容。

cURL 範例：
伺服器回應：
-HTTP 狀態碼： 200 OK
-Response Body： 回傳帶有完整 meta.versionId 與配發 id 的 Patient JSON。

3. Update（更新資源）：PUT
   更新現有資源。FHIR 的 PUT 要求在 URL 中帶入 ID，並且在 Body 中附帶該 ID。

cURL 範例（更新病患聯絡電話）：

伺服器回應特徵：
-HTTP 狀態碼： 200 OK
-Response Header： Location 中的版本號會自動遞增，變為 _history/2。

4. Delete（刪除資源）：DELETE
   在醫療法規中，病歷通常不允許實體抹除（Hard Delete）。FHIR 的 DELETE 通常執行邏輯刪除（Soft Delete）。

cURL 範例：
伺服器回應：
-HTTP 狀態碼： 204 No Content 或 200 OK（含 OperationOutcome）。
-若再次發送 GET /Patient/1，伺服器會回傳 410 Gone，明確表示該資源曾存在但已被註銷。

三、進階檢索：Search Parameters 與 Bundle 結構
在臨床系統中，護理師很少直接依據內部 ID 查詢，而是透過「病歷號」、「身分證號」或「量測時間區間」檢索。

關鍵認知：任何 Search 操作回傳的結果，永遠是一個 resourceType: "Bundle"，且 type: "searchset"！

1. 識別碼精確搜尋（Token Search）
   使用標準格式 [system]|[value] 查詢特定病歷號的病患：
   

2. 姓名模糊查詢（String Search）
   查詢姓氏為「蔡」的病患：

3. 日期區間搜尋（Date Search 與 Prefixes）
   查詢某位病患在特定時間之後的所有體溫 Observation 記錄。FHIR 支援使用運算子前綴（如 ge 代表大於等於、lt 代表小於）：

四、解析 SearchSet Bundle 結構
當查詢成功時，伺服器回傳的 Bundle 結構如下：
-total：符合搜尋條件的總筆數。
-link：提供 self、next、previous 等分頁連結，前端或 API 呼叫端可以直接根據 next URL 進行換頁撈取。
-entry[]：查詢結果陣列，每一筆資料包覆在 resource 欄位中。

小結
今天我們完成了模組一的最後一塊拼圖：
1.掌握了 FHIR HTTP 標頭要求（application/fhir+json）與狀態碼規範。
2.實測了標準 RESTful CRUD（POST 配發 ID、PUT 版本遞增、DELETE 產生 410 Gone）。
3.熟練了臨床最核心的 Token 與 Date 搜尋語法，並解析了容器載體 Bundle (searchset)。

至此，模組一：醫療資訊標準化與環境建置 已全數完工！

明天 Day 7，我們將正式進入 模組二：護理資訊系統（NIS）業務與資料塑模，從前線護理人員的臨床視角出發，深度拆解行動護理系統（NIS）的真正痛點與防錯機制！